- Add unifiedRecipeOperations.test.ts with 16 test cases
- Test all UnifiedItem[] recipe operations (add, update, remove, scale, etc.)
- Verify quantity calculations and scaling functionality
- Test error handling for edge cases (zero quantity, negative values)
- All tests pass, validating UnifiedRecipe operations work correctly

This ensures the UnifiedItem[] Recipe domain operations are thoroughly tested
and ready for use in the UI layer migration.

- Add UnifiedRecipe and UnifiedRecipeContext support to RecipeEditContext
- Create UnifiedRecipeEditView component for native UnifiedItem[] operations
- Add calcUnifiedRecipeMacros() and calcUnifiedRecipeCalories() to macroMath
- UnifiedRecipeEditView removes manual conversions, uses unifiedRecipeOperations
- All copy/paste, edit, delete operations work natively with UnifiedItem[]
- Maintains full compatibility with existing Recipe flows

Migration progress: Backend ✅ Domain ✅ UI Components ✅ Next: Application layer

- GroupChildrenEditor now uses saveUnifiedRecipe() instead of insertRecipe()
- Creates UnifiedRecipe directly from UnifiedItem[] children (no conversion)
- Removes convertUnifiedItemToItem() conversion function (no longer needed)
- Uses createNewUnifiedRecipe() for direct UnifiedItem[] support
- Demonstrates end-to-end UnifiedRecipe workflow from UI to persistence
- Clean up unused imports (Item, createItem, macro calculation utilities)

Migration progress: Backend ✅ Domain ✅ UI ✅ Application ✅ (partial)
GroupChildrenEditor serves as reference implementation for UnifiedRecipe usage.

- UnifiedItemName now uses fetchUnifiedRecipeById() instead of legacy repository
- Uses convertUnifiedRecipeToRecipe() for compatibility with existing comparison logic
- Maintains all existing functionality (manual edit detection) seamlessly
- Demonstrates how to integrate UnifiedRecipe with legacy conversion utilities
- Another practical example of UnifiedRecipe application layer migration

Migration benefits:
- Uses unified application services throughout
- Maintains backward compatibility for complex comparison logic
- Shows pattern for gradual migration with conversion bridges

MIGRATION COMPLETE ✅

The Recipe entity has been successfully migrated from legacy Item[] to UnifiedItem[]
in-memory operations while maintaining full backward compatibility.

Achievements:
✅ Domain layer: UnifiedRecipe types, operations, conversions, tests
✅ Infrastructure: UnifiedRecipeRepository with automatic DB conversion
✅ Application: unifiedRecipe services, macro calculations, error handling
✅ UI: UnifiedRecipeEditView, context providers, practical migrations
✅ Patterns: Established pure and hybrid migration approaches
✅ Examples: GroupChildrenEditor (pure), UnifiedItemName (hybrid)
✅ Compatibility: All legacy workflows continue to function
✅ Performance: Eliminated conversion overhead in new workflows

The migration provides a robust foundation for future recipe enhancements and
serves as a reference implementation for similar entity migrations.

…m filtering

… and update processes

…rting

… repository context

… tracking

Added a new "Unlink Recipe" button to the  component. This button allows users to unlink a recipe from a group, transforming it back into a group item. Updated visibility logic to ensure the button only appears when the item is a recipe.

…odal

Add ability to open RecipeEditModal from UnifiedItemEditModal when editing recipe items. This allows users to edit the original recipe directly from the unified item interface.

- Add RecipeEditModal import and integration
- Add recipe edit button (✏️) for recipe items when original recipe is available
- Implement recipe save/delete handlers with repository integration
- Add proper modal state management and context provider
- Synchronize changes back to UnifiedItem after recipe updates
- Include proper error handling and modal cleanup

…and governance rules

Phase 4: UI Migration for Item/ItemGroup Unification

- Create SearchLoadingIndicator component for inline loading states
- Add loading spinner to TemplateSearchBar during active searches
- Add loading overlay to TemplateSearchResults during data fetches
- Add loading indicators to TemplateSearchTabs during tab changes
- Improve TemplateSearchModal fallback loading message
- Add ARIA attributes for accessibility
- Maintain consistent loading patterns with existing components

Resolves #765

… for tab state

- Refactor tabId, tabTitle, and isActive to be accessors for improved reactivity
- Remove unused loading indicator logic from tab rendering
- Affects src/sections/search/components/TemplateSearchTabs.tsx

… observations

…ateSearch components

- Added  to the search input in  for better accessibility.
- Refactored  to use a  variable for cleaner code and improved readability.

… status and governance rules

- Introduced Planning mode in  for generating implementation plans.
- Enhanced memory integration checklist in .
- Updated tools list in  to include memory-related functionalities.

…bs component

…ntation prompts

…SearchTabs component

…oup unification

Add loading indicators for search modals

refactor: complete UnifiedItem migration by removing all legacy Item/ItemGroup modules

- Create optimized PostgreSQL RPC function search_favorite_foods_with_scoring
- Modify fetchFoodsByName to use new RPC when allowedFoods parameter provided
- Add tests to verify favorites filtering behavior works correctly
- Resolves issue where favorites search returned all foods instead of filtering

Closes #990

…from database

- Modify search_favorite_foods_with_scoring RPC to accept user_id instead of favorite_ids array
- RPC now queries users table directly to get favorite_foods, eliminating parameter passing
- Update FoodSearchParams to include userId and isFavoritesSearch boolean flags
- Simplify fetchFoodsByName logic to use new RPC interface
- Update tests to reflect simplified interface without allowedFoods parameter
- Improve performance by reducing data transfer between client and database

This approach is more efficient as it:
- Eliminates the need to pass favorite IDs from client to database
- Reduces network payload size
- Centralizes favorite foods logic in the database layer
- Maintains the same functionality with cleaner interface

…_scoring RPC

- Qualify users table reference with alias 'u' to avoid column name conflict
- Resolves PostgreSQL error 42702 about ambiguous 'id' column reference
- Function now properly distinguishes between return column 'id' and table column 'u.id'

fix(search): implement optimized favorites search with database-direct RPC

The synchronizeRecipeItemWithOriginal function now correctly updates
the parent recipe's quantity field to match the sum of synchronized
children quantities, maintaining data consistency.

Previously, only the children array was updated while the parent
quantity remained stale, causing inconsistency between ingredient
totals and recipe quantity.

Changes:
- Calculate total quantity from synchronized children
- Update parent recipe quantity field
- Add comprehensive tests for quantity consistency
- Verify edge cases (empty children, multiple children)

Fixes #991

fix(unified-item): resolve recipe quantity inconsistency after synchronization

…erns

- Remove 31 obsolete audit documents (1,086 lines) with completed migrations
- Clean redundant test anti-patterns: type validation, Zod schema spam, property assignment tests
- Remove extreme edge case tests and round-trip testing redundancy
- Reduce test suite from 5,922 to 5,282 lines while preserving business logic tests
- Maintain architectural documentation (ARCHITECTURE_AUDIT.md, RECIPE_MIGRATION_AUDIT.md)